Document importation into secure element

ABSTRACT

Techniques are disclosed relating to authenticate a user with a mobile device. In one embodiment, a computing device includes a short-range radio and a secure element. The computing device reads, via the short-range radio, a portion of credential information stored in a circuit embedded in an identification document issued by an authority to a user for establishing an identity of the user. The computing device issues, to the authority, a request to store the credential information, the request specifying the portion of the credential information. In response to an approval of the request, the computing device stores the credential information in the secure element, the credential information being usable to establish the identity of the user. In some embodiments, the identification document is a passport that includes a radio-frequency identification (RFID) circuit storing the credential information, and the request specifies a passport number read from the RFID circuit.

The present application is a continuation of U.S. application Ser. No.15/415,467, entitled “DOCUMENT IMPORTATION INTO SECURE ELEMENT,” filedJan. 25, 2017, which claims priority to U.S. Provisional App. No.62/286,944, entitled “DOCUMENT IMPORTATION INTO SECURE ELEMENT,” filedJan. 25, 2016; the disclosures of each of the above-referencedapplications are incorporated by reference herein in their entireties.

BACKGROUND Technical Field

This disclosure relates generally to mobile devices, and, morespecifically, to authenticating a user with a mobile device.

Description of the Related Art

Various governments are now issuing various forms of identification thatare capable of storing identification information that can be used toauthenticate a user. For example, modern passports (called e-Passports)may include an electronic chip that stores a passport holder's name,date of birth, and other forms of information. When a person is passingthrough customs, the person may present the passport to a customsofficer, who places the passport on a reader to extract informationstored in the passport. Upon verifying the information printed on thepassport against the internally stored information, the officer mayconfirm the identity of the holder and allow the holder passage throughcustoms.

BRIEF DESCRIPTION OF THE DRAWINGS

FIG. 1 is a block diagram illustrating one embodiment of system forauthenticating a user with a mobile device.

FIG. 2 is a block diagram illustrating one embodiment of the mobiledevice.

FIGS. 3A-3C are communication diagrams illustrating embodiments ofenrollment and authentication processes used by the authenticationsystem.

FIG. 4 is a block diagram illustrating another embodiment of a systemfor authenticating a user with a mobile device.

FIGS. 5A and 5B are communication diagrams illustrating embodiments ofenrollment and authentication processes used by the authenticationsystem.

This disclosure includes references to “one embodiment” or “anembodiment.” The appearances of the phrases “in one embodiment” or “inan embodiment” do not necessarily refer to the same embodiment.Particular features, structures, or characteristics may be combined inany suitable manner consistent with this disclosure.

Within this disclosure, different entities (which may variously bereferred to as “units,” “circuits,” other components, etc.) may bedescribed or claimed as “configured” to perform one or more tasks oroperations. This formulation—[entity] configured to [perform one or moretasks]—is used herein to refer to structure (i.e., something physical,such as an electronic circuit). More specifically, this formulation isused to indicate that this structure is arranged to perform the one ormore tasks during operation. A structure can be said to be “configuredto” perform some task even if the structure is not currently beingoperated. A “biosensor configured to collect biometric information” isintended to cover, for example, an integrated circuit that has circuitrythat performs this function during operation, even if the integratedcircuit in question is not currently being used (e.g., a power supply isnot connected to it). Thus, an entity described or recited as“configured to” perform some task refers to something physical, such asa device, circuit, memory storing program instructions executable toimplement the task, etc. This phrase is not used herein to refer tosomething intangible. Thus, the “configured to” construct is not usedherein to refer to a software entity such as an application programminginterface (API).

The term “configured to” is not intended to mean “configurable to.” Anunprogrammed FPGA, for example, would not be considered to be“configured to” perform some specific function, although it may be“configurable to” perform that function and may be “configured to”perform the function after programming.

Reciting in the appended claims that a structure is “configured to”perform one or more tasks is expressly intended not to invoke 35 U.S.C.§ 112(f) for that claim element. Accordingly, none of the claims in thisapplication as filed are intended to be interpreted as havingmeans-plus-function elements. Should Applicant wish to invoke Section112(f) during prosecution, it will recite claim elements using the“means for” [performing a function] construct.

As used herein, the terms “first,” “second,” etc. are used as labels fornouns that they precede, and do not imply any type of ordering (e.g.,spatial, temporal, logical, etc.) unless specifically stated. Forexample, in a processor having eight processing cores, the terms “first”and “second” processing cores can be used to refer to any two of theeight processing cores. In other words, the “first” and “second”processing cores are not limited to logical processing cores 0 and 1,for example.

As used herein, the term “based on” is used to describe one or morefactors that affect a determination. This term does not foreclose thepossibility that additional factors may affect a determination. That is,a determination may be solely based on specified factors or based on thespecified factors as well as other, unspecified factors. Consider thephrase “determine A based on B.” This phrase specifies that B is afactor is used to determine A or that affects the determination of A.This phrase does not foreclose that the determination of A may also bebased on some other factor, such as C. This phrase is also intended tocover an embodiment in which A is determined based solely on B. As usedherein, the phrase “based on” is thus synonymous with the phrase “basedat least in part on.”

DETAILED DESCRIPTION

The present disclosure describes embodiments in which a person maypresent identification information through a mobile device instead ofpresenting a traditional form of identification. As will be describedbelow, in various embodiments, a mobile device includes a short-rangecommunication interface (e.g., a near-field communication (NFC) radio)and a secure element configured to store identification information of auser. As used herein, the term “secure element” is to be interpretedaccording to its understood meaning in the art, and refers to circuitrythat is configured to store information in a tamper-resistant mannerthat resists unauthorized extraction of that information. In such anembodiment, when the user presents the mobile device to a correspondingreader attempting to authenticate the user, the mobile device mayattempt to verify the identity of the user (e.g., via a biosensor in themobile device in some embodiments) before permitting the secure elementto provide the identification information to the reader. For example, inone embodiment, the secure element is configured to store informationpresent in a passport issued to the user. Accordingly, when the user ispassing through a customs checkpoint, the user may present the mobiledevice to a reader operated by a customs agent. After the mobile deviceauthenticates the user's identity, the secure element may convey thepassport information to the reader. In some instances, being able toauthenticate using a mobile device may help expedite establishing anidentity of user and provide the convenience of performing anauthentication without presenting the identification document.

In various embodiments, the mobile device may receive authorization tostore the identification information captured in an enrollment processwith the authority that issued the identification document. In someembodiments, this process may include the mobile device using theshort-range communication interface to read information stored incircuitry included in the identification document—e.g., identificationinformation stored in a radio-frequency identification (RFID) tagembedded in a passport. The secure element may then issue a request tothe authority for permission to store the identification information,the request specifying at least portion of the read information—e.g., apassport number. The authority may then validate the request and permitthe secure element to store the information, which may be signed by theauthority in order to ensure validity of the information. In someembodiments, the enrollment process also includes the secure elementgenerating a public-key pair and issuing a certificate signing request(CSR) to the authority in order to receive a corresponding digitalcertificate and register the public-key pair with the authority. (Asused herein, the term “digital certificate” (or “certificate”) is to beinterpreted according to its understood meaning in the art, and refersto an electronic document that is usable to prove ownership of a publickey and is signed by a trusted certificate authority (CA).) In someembodiments, the CSR is signed by a trusted key, which is stored in thesecure element during fabrication and may be a certified private keyhaving its own certificate signed by a trusted authority attesting tothe validity of the stored key. In various embodiments, once thecertificate has been issued for the newly generated key pair, theprivate key of the pair may be used to generate digital signatures toauthenticate a user in lieu of a private key stored in circuitry of theidentification document. Embodiments of these concepts are described infurther detail below with respect to FIGS. 1-3C.

In some embodiments, the mobile device may perform an authenticationthat includes the secure element confirming whether a holder of anidentification document has an attribute satisfying some criterionwithout providing that attribute (or at least providing some informationabout that attribute without providing all information about thatattribute). For example, in one embodiment, a person may be attemptingto purchase an item that requires the merchant to confirm whether an ageof the person satisfies some threshold value. In such an embodiment,rather than having the user present the identification document (e.g., adriver license), the reader of the merchant may ask the secure elementto confirm whether the user of the mobile device is old enough topurchase the item. Based on a stored date of birth and a successfulauthentication of the user (e.g., via a biosensor), the secure elementmay then answer in the affirmative or the negative (as opposed toactually communicating the user's age or date of birth). In doing so,the mobile device is able to protect a user's identificationinformation, yet still adequately answer the merchant's inquiry.Embodiments of these concepts are described in further detail below withrespect to FIGS. 4-5B.

Turning now to FIG. 1 , a block diagram of an authentication system 100is depicted. In the illustrated embodiment, authentication system 100includes an identification document 110, a verification system 120,mobile device 130, and authorization system 140. As shown, document 110may include an RFID tag 112. Verification system 120 may include areader 122 and backend 124. Mobile device 130 may include a near-fieldcommunication (NFC) interface 132, a secure element (SE) 134, and abiosensor 138. In some embodiments, system 100 may be arrangeddifferently than shown. For example, in some embodiments, reader 122 andbackend 124 may be located in distinct systems. In some embodiments,document 110 may include no RFID tag 112 or embed circuitry other thanan RFID tag 112. In some embodiments, SE 134 may be external to NFCinterface 132.

Identification document 110 corresponds to any suitable form physicalidentification usable to establish an identity of a holder such as apassport, driver license, government-issued ID, student ID, etc.Accordingly, document 110 presents various forms of information about auser including, for example, a user's name, date of birth, place ofresidence, etc. Document 110 may include a photograph of the documentholder. Document 110 may also include a unique identification numbersuch as passport number, driver license number, etc. Document 110 mayalso identify the issuing authority such as the particular country,government, university, etc. In various embodiments, document 110 maynot only depict this information on the face of the document, but alsostore this information in circuitry or a magnetic strip embedded in thedocument 110 shown as identification information 114. For example, inthe illustrated embodiment, document 110 includes RFID tag 112 forstoring this information 114. In such an embodiment, document 110 maystore information in compliance with known standards such as the ISO/IEC18000 standards and/or ISO/IEC 14443 standards. In other embodiments,document 110 includes other forms of circuitry such as a smart card chipcompliant with ISO/IEC 7816, a Bluetooth™ enabled chip, etc. In someembodiments, information stored in this circuitry may be signed by theis suing authority in order to prevent modification; the embeddedcircuitry may also include a digital certificate usable to verify thedigital signature. In some embodiments, the circuitry embedded indocument 110 is configured to store a private key and to generatedigital signatures with the key in order to authenticate the holder.

Verification system 120, in one embodiment, is a computer systemconfigured to authenticate a person that presents identificationdocument 110. In various embodiments, system 120 uses reader 122 forextracting information 114 stored in document 110. Accordingly, reader122 may include a short-range radio for communicating with the RFID tag112 in order to read the identification information stored in the tag112. In some embodiments, reader 122 may also include a display thatpresents the information 114 to a reviewer such as a customs agentattempting to verify passport information. In various embodiments,verification system 120 confirms information read by reader 122 againsta backend system 124, which may be implemented by one or more computersystems located elsewhere from reader 122. In some embodiments, backend124 maintains a database, which may include the information stored indocument 110, an indication of whether document 110 is still valid(e.g., has not been reported as being lost), etc. In some embodiments,backend 124 implements a certificate authority (CA) capable of issuingcertificates for received certificate signing requests (CSRs). In someinstances, reader 122 and/or backend 124 are operated by the authoritythat issued the identification document 110. In other instances, reader122 may be operated by another entity such as a customs agent located inanother country, a merchant (as discussed with respect to FIG. 4 ), etc.In some embodiments, backend 124 may be operated by a third-partyinteracting with the issuing authority.

Mobile device 130 corresponds to any suitable form of device such asmobile phone, tablet, wearable device (e.g., a watch), laptop, etc. Asnoted above, in various embodiments, mobile device 130 is configured tostore identification information 114 from document 110 and present thatto verification system 120 in order to authenticate a user of mobiledevice 130, which is also a holder of document 110. In the illustratedembodiment, mobile device 130 (or more specifically SE 134) interactswith identification document 110, verification system 120, and/orauthorization system 140 via NFC interface 132.

Near-field communication (NFC) interface 132, in one embodiment, is ashort-range radio circuit configured to implement one or more NFCstandards such as those defined by ISO/IEC 18000. In other embodiments,interface 132 may implement other short-range radio access technologies(RATs) such as Bluetooth™, ZigBee™, Wi-Fi™, etc. In some embodiments,mobile device 130 may also include a long-range radio for interactingwith systems 120 and 140 such one supporting various cellular RATs.

Secure element (SE) 134, in one embodiment, is a secure elementconfigured to store identity information 114, which is also stored inRFID 112. Accordingly, SE 134 employs various techniques to resistantextraction of information 114 such as using strong encryption, having arestricted access interface, attempting to destroy information 114 inresponse to tamper detection, etc. In some embodiments, SE 134 isconfigured to store all information 114 that is also stored in RFID tag112. In other embodiments, SE 134 is configured to store a token that isusable to retrieve some or all of this information 114 from backend 124.For example, in one embodiment, rather than store a photograph that isstored in tag 112, SE 134 stores a token that is usable to retrieve thisphotograph—thus enabling SE 134 to conserve memory. In variousembodiments, when a user presents mobile device 130 to a reader 122, NFCinterface 132 presents SE 134 with a request for information from reader122. Upon receiving the request, SE 134 may verify that the user hasbeen authenticated by mobile device 130 before providing information 114to reader. As will be discussed below, in some embodiment, thisauthentication may be performed using biosensor 138. In otherembodiments, the user may be authenticated differently such as, in oneembodiment, being presented with a prompt on a touch screen of mobiledevice 130 and asked to enter a passcode. Upon a successfulauthentication of the user, in various embodiments, SE 134 communicatesinformation 114 to reader 122 via an encrypted connection establishedthrough NFC interface 132. Prior to interacting with verification system120, mobile device 130 may perform an enrollment process in order for SE134 to be permitted to store information 114 and interact withverification system 120.

Authorization system 140, in one embodiment, is a computer systemconfigured to facilitate enrollment of mobile device 130. In someembodiments, authorization system 140 is operated by the authority thatissued document 110 (or a third party that interacts with the issuingauthority). In various embodiments, mobile device 130 begins enrollmentby reading at least a portion of information 114 stored inidentification document 110, such as the identification number and thename of the person that holds document 110. In the illustratedembodiment, mobile device 130 reads this information from RFID tag 112via NFC interface 132; in other embodiments, this information may beextracted differently such as using a camera of device 130 to captureinformation from document 110, having a user manually enter thisinformation, etc. Upon reading this information, SE 134 may encrypt thisinformation and communicate it in an enrollment request 136 to system140. Although depicted as being communicated via NFC interface 132, insome embodiment, this request 136 via another interface of mobile device130 such a cellular interface. Authorization system 140 may then attemptto validate this request 136—i.e., confirm that the request 136 iscoming from a phone operated by the holder of document 110.

In some embodiments, authorization system 140 validates the request 136through one or more back channels. For example, in one embodiment,authorization system 140 may rely on a trusted person, such a customsagent, to confirm that device 130 is in possession of document 110'sholder at the time of enrollment. In other embodiments, authorizationsystem 140 may present a website usable to assist in validating arequest 136. For example, in one embodiment, this website may allow auser to validate the request via the Global Online Enrollment System(GOES) operated by the U.S. Department of Homeland Security. In anotherembodiment, authorization system 140 may be able to sufficientlyvalidate the request 136 by verifying its information againstinformation stored in backend 124.

In various embodiments, once the authentication system 140 hassuccessfully validated the request 136, authorization system 140 isconfigured to provide an authorization indication 142 to SE 134 in orderto indicate that SE 134 has been authorized to store identificationinformation 114. In various embodiments, this indication 142 includes asigned copy of the information 114 that is stored in document 110(and/or a signed copy of a token stored in lieu of storing information114 in in some embodiments). In some embodiments, system 140 obtainsinformation 114 by querying backend 124 using the information providedin request 136 such as an identification number of document 110. Inother embodiments, SE 134 may be able to successfully read allinformation 114 from RFID tag 112 and is configured to include thisinformation in its request 136. In such an embodiment, system 140 maymerely sign the request 136 including the information 114 within it andprovide this signed request as the authorization indication 142. Inanother embodiment, indication 142 includes a token generated by system140 that can be presented to verification system 120 in order toretrieve information 114 from backend 124.

In some embodiments, the enrollment process also includes SE 134establishing a private key that can be used to generate digitalsignatures to authenticate a user. In such an embodiment, SE 134 isconfigured to generate a public-key pair and to issue a CSR to receive acorresponding certificate. In some embodiments, SE 134 issues the CSR tobackend 124 and includes the received authentication indication 142 inthe CSR. Backend 124 acting as a certificate authority may then issuethe corresponding certificate to SE 134 for storage. In someembodiments, backend 124 may also store a copy of certificate andassociate it the information that it maintains on the holder of document110. In other embodiments, this CSR may be sent as part of request 136(or in conjunction with request 136) to authorization system 140.

As noted above, in some embodiments, biosensor 138 is used toauthenticate a user of mobile device 130 before SE 134 providesidentification information 114 to reader 122. Biosensor 138 correspondsto any suitable sensor configured to detect biometric data for a user ofmobile device 130. Biometric data is data that uniquely identifies theuser among other humans (at least to a high degree of accuracy) based onthe user's physical or behavioral characteristics. For example, in someembodiments, biosensor 138 is a finger print sensor that capturesfingerprint data from the user. In some embodiments, other types ofbiometric data may be captured by sensor 260A such as voice recognition(identifying the particular user's voice), facial recognition; irisscanning, etc.

In various embodiments, SE 134 is configured to associate identificationinformation 114 with biometric data captured by biosensor 138 whenenrollment is performed in order to ensure that a person laterattempting to authenticate with mobile device 130 is the same personduring enrollment. In some embodiments, SE 134 associates information114 with the biometric data by storing a unique index value thatcorresponds with the captured biometric data. SE 134 may alsocryptographically bind this value to information 114 by encrypting themtogether. As will be described with respect to FIG. 2 , in someembodiments, a separate circuit (referred to below as a secure enclaveprocessor) is configured to store previously captured biometric data andcompare it against newly acquired biometric during an authentication. Insome embodiments, when this circuitry detects a match, it indicates toSE 134 not only that a match was detected, but also provides a uniqueindex value associated with the match. In such an embodiment, SE 134uses the index value to look up stored information 114. For example, inone embodiment, a user may register multiple fingers during anenrollment process, where each finger is assigned a unique index valuethat is associated with the newly stored information 114. When a userlater attempts to authenticate with a reader 122 and uses one of thepreviously registered fingers (or a combination of the fingers in someembodiments), the secure enclave processor may provide the correspondingunique index value (or values), which is used by SE 134 to lookup theinformation 114 and provide to reader 122. If, however, the user (oranother user) attempts to register another finger after enrollment, thesecure enclave processor may provide a unique index value, which mayresult in SE 134 being unable to look up the previously storedinformation 114—thus, preventing SE 134 from providing the requestedinformation 114.

Embodiments of the enrollment and authentication processes are describedin further detail below with respect to FIGS. 3A-3C.

Turning now to FIG. 2 , a block diagram of a mobile device 130 isdepicted. As noted above, mobile device 130 may include NFC interface132, SE 134, and biosensor 138. In the illustrated embodiments, mobiledevice 130 further includes a secure enclave processor (SEP) 210,cellular interface 220, CPU 230, memory 240, peripherals 250 coupled viaa communication fabric 260. As shown, SEP 210 may include one or moreprocessors P 212, a secure memory 214, and one or more securityperipherals 216. SE 134 may include one or more processors P 222 and amemory 224. CPU 320 may include one or more processors P 322. Memory 240may store an interface application 242. In some embodiments, mobiledevice 130 may be implemented differently from shown.

As noted above, in some embodiments, SEP 210 is configured to maintainpreviously captured biometric data of an authorized user and compare itagainst newly received data captured by biosensor 138 in order toauthenticate a user. (In another embodiment, biosensor 138 or SE 134 mayperform the comparison.) In the illustrated embodiment, SEP 210 isconfigured to store biometric data collected from fingerprints asfingerprint templates 218. In such an embodiment, each template 218 maycorrespond to a particular registered finger and be assigned a uniqueindex value. As noted above, in some embodiments, if fingerprint datareceived from biosensor 138 matches the fingerprint data stored in atemplate 218, SEP 210 is configured to provide the unique index valueassociated with the matching template 218 to SE 134, which, in turn,uses the index value to look up the corresponding identificationinformation 114 associated with that value. In some embodiments, SEP 210may store multiple templates 218 associated with a set of identificationinformation 114, where each finger individually or a combination offingers may be used to enable the release of identification information114. In various embodiments, communications between SEP 210, SE 134, andbiosensor 138 are encrypted such that another entity, such as CPU 230,is unable to view their communications.

In various embodiments, SEP 210 implements a secure element, distinctfrom SE 134, in order to securely store biometric data. Accordingly, invarious embodiments, SEP 125 is isolated from the rest of the mobiledevice 130 except for a carefully controlled interface (thus forming asecure enclave for SEP processor 212, secure memory 214, and securityperipherals 216). Because the interface to SEP 210 is carefullycontrolled, direct access to SEP processor 212, secure memory 214, andsecurity peripherals 216 may be prevented. In one embodiment, a securemailbox mechanism may be implemented. In the secure mailbox mechanism,external devices may transmit messages to an inbox. SEP processor 212may read and interpret the message, determining the actions to take inresponse to the message. Response messages from the SEP processor 212may be transmitted through an outbox, which is also part of the securemailbox mechanism. Other interfaces that permit only the passing ofcommands/requests from the external components and results to theexternal components may be used. No other access from the externaldevices to SEP 210 may be permitted, and thus the SEP 210 may be“protected from access”.

More particularly, software executed anywhere outside SEP 210 may beprevented from direct access to the secure components with the SEP 210.SEP processor 212 may determine whether a command is to be performed. Insome cases, the determination of whether or not to perform the commandmay be affected by the source of the command. That is, a command may bepermitted from one source but not from another.

In some embodiments, SEP processor 212 may execute securely loadedsoftware that facilitates implementing functionality descried withrespect to SEP 210. For example, a secure memory 214 may includesoftware executable by SEP processor 212. One or more of the securityperipherals 216 may have an external interface, which may be connectedto a source of software (e.g. a non-volatile memory such as Flashmemory). In another embodiment, the source of software may be anon-volatile memory coupled to another peripheral 216, and the softwaremay be encrypted to avoid observation by a third party. The softwarefrom the source may be authenticated or otherwise verified as secure,and may be executable by SEP processor 212. In some embodiments,software may be loaded into a trust zone in memory 214 that is assignedto the SEP 210, and SEP processor 212 may fetch the software from thetrust zone for execution. The software may be stored in the memory 240in encrypted form to avoid observation. Despite the steps taken toensure security of the secure software, the secure software may still beprevented from directly accessing/obtaining stored private keys. Onlyhardware may have access to private keys, in an embodiment.

Security peripherals 216 may be hardware configured to assist in thesecure services performed by SEP 210. Accordingly, security peripherals216 may include authentication hardware implementing/acceleratingvarious authentication algorithms, encryption hardware configured toperform/accelerate encryption, secure interface controllers configuredto communicate over a secure interface to an external (to mobile device130) device, etc.

In some embodiments, SE 134 may implement similar functionality as SEP210 in order to restrict access to confidential information stored inmemory 224 such as identification information 114 and public-keyinformation 228. For example, SE 134 may implement a mailbox to restrictaccess to processor 222 and memory 224. In various embodiments, SEprocessor 222 also executes securely loaded software in order toimplement functionality described herein such as applets 226 stored inmemory 224.

Applets 226, in one embodiment, are executable to perform enrollment ofmobile device 130 and authentication with a reader 122. With respect toenrollment, applets 226 may be executable to extract information 114from an RFID tag 112 and issue a corresponding enrollment request 136.In some embodiments, applets 226 are executable to generate public-keypairs and obtain corresponding certificates, which may be stored inmemory 224 as public-key information 228. With respect toauthentication, applets 226 may service requests from information 114from readers 122 and may process comparison results indicated by SEP210. In some embodiments, if a particular comparison performed by SEP210 does not result in a match, SE 134 may be configured to restrict (orstop) execution an applet 226 in order to prevent it from servicing arequest from information 114 from a reader 122.

Interface application 242, in one embodiment, is executable tofacilitate interfacing between SEP 210, SE 134, and a user of mobiledevice 130 when enrollment and authentication are performed.Accordingly, application 242 may provide various prompts to the userinstructing the user to perform various actions during these processes.Application 242 may also activate biosensor 138, SEP 210, and/or SE 134when appropriate during these processes. Various actions performed byapplication 242 are described in further detail below with respect toFIGS. 3A-3C.

Cellular Interface 220, in one embodiment, is a long-range radioconfigured to facilitate interaction between mobile device 130 and oneor more external systems such as systems 120 and 140. Cellular link 220may include suitable circuitry for interfacing with long-range networkssuch as a baseband processor, analog RF signal processing circuitry(e.g., including filters, mixers, oscillators, amplifiers, etc.),digital processing circuitry (e.g., for digital modulation as well asother digital processing), one or more antennas, etc. Cellular interface220 may be configured to communicate using any of multiple radio accesstechnologies/wireless communication protocols such as GSM, UMTS,CDMA2000, LTE, LTE-A, etc.

As mentioned above, CPU 230 may include one or more processors 232.Generally, a processor may include circuitry configured to executeinstructions defined in an instruction set architecture implemented bythe processor. Processors 232 may include (or correspond to) processorcores implemented on an integrated circuit with other components as asystem on a chip (SOC) or other levels of integration. Processors 232may further include discrete microprocessors, processor cores and/ormicroprocessors integrated into multichip module implementations,processors implemented as multiple integrated circuits, etc.

Processors 232 may execute the main control software of the system, suchas an operating system. Generally, software executed by CPU 230 duringuse may control the other components of the system to realize thedesired functionality of the system. The processors may also executeother software. These applications may provide user functionality, andmay rely on the operating system for lower-level device control,scheduling, memory management, etc. Accordingly, processors 232 (or CPU230) may also be referred to as application processors. CPU 230 mayfurther include other hardware such as an L2 cache and/or an interfaceto the other components of the system (e.g. an interface to thecommunication fabric 260).

Memory 240 may generally include the circuitry for storing data. Forexample, memory 240 may be static random access memory (SRAM), dynamicRAM (DRAM) such as synchronous DRAM (SDRAM) including double data rate(DDR, DDR2, DDR3, DDR4, etc.) DRAM. Low power/mobile versions of the DDRDRAM may be supported (e.g. LPDDR, mDDR, etc.). Device 130 may include amemory controller (not shown) that may include queues for memoryoperations, for ordering (and potentially reordering) the operations andpresenting the operations to the memory 240. The memory controller mayfurther include data buffers to store write data awaiting write tomemory and read data awaiting return to the source of the memoryoperation. In some embodiments, the memory controller may include amemory cache to store recently accessed memory data. In some embodimentsmemory 330 may include program instructions, such as instructions ofapplication 242, that are executable by one or more processors 232 tocause device 130 to perform various functionality described herein withrespect to device 130.

Peripherals 250 may be any set of additional hardware functionalityincluded in device 130. For example, peripherals 340 may include videoperipherals such as an image signal processor configured to processimage capture data from a camera or other image sensor, displaycontrollers configured to display video data on one or more displaydevices, graphics processing units (GPUs), video encoder/decoders,scalers, rotators, blenders, etc. Peripherals 250 may include audioperipherals such as microphones, speakers, interfaces to microphones andspeakers, audio processors, digital signal processors, mixers, etc.Peripherals 250 may include interface controllers for various interfacesincluding interfaces such as Universal Serial Bus (USB), peripheralcomponent interconnect (PCI) including PCI Express (PCIe), serial andparallel ports, etc. Peripherals 250 may include networking peripheralssuch as media access controllers (MACs). Any set of hardware may beincluded.

Communication fabric 360 may be any communication interconnect andprotocol for communicating among the components of device 130.Communication fabric 360 may be bus-based, including shared busconfigurations, cross bar configurations, and hierarchical buses withbridges. Communication fabric 360 may also be packet-based, and may behierarchical with bridges, cross bar, point-to-point, or otherinterconnects.

Although FIG. 2 depicts components within mobile device 130, it is notedthat similar components may exist in computer systems used to implementother functionality described herein such as functionality describedwith respect to verification system 120 and authorization systems 140.Accordingly, these systems may also include CPUs, memory, variousnetwork interfaces, and peripherals such as those described above.

Turning now to FIG. 3A, a communication diagram of an enrollment process300A is depicted. As discussed above, in various embodiments, enrollmentprocess 300A may be performed by mobile device 130 in order to obtainauthorization to store identification information 114 from anidentification document 110.

As shown, process 300A begins at 302 with application 242 issuing arequest to read an identification number, such as a passport number orother portion of information 114, via NFC interface 132. In response toreceiving the number at 304, application 242 activates biosensor 306 tocollect biometric data from the user before providing the identificationnumber to SE 134 at 308. In the illustrated embodiment, SE 134 thenissues an enrollment request 136 at 310 that includes the number, anonce, and a digital signature. (As used herein, the term “nonce” is tobe interpreted according to its understood meaning in the art, andincludes an arbitrary number that is only used once in a cryptographicoperation.) In some embodiments, the digital signature is generatedusing a trusted key (e.g., a certified private key) stored in SE 134during fabrication, and authentication system 140 may include thecorresponding certificate. At 312, authentication systems 140 validatesthe request by verifying the identification number and the digitalsignature. In some embodiments, the validation may also includeverifying the request via one or more back channels as discussed above.Upon a success validation, authentication system 140 provides anauthorization indication 142 at 314 to SE 134. At 316, SE 134 generatesa public-key pair to be associated with the identification information114 and usable to authenticate the user. At 318, SE 134 then issues, toverification system 120, a certificate signing request (CSR) that, inthe illustrated embodiment, includes the previous enrollment request136, the received authentication indication 142, a public key of thegenerated pair, and a digital signature generated by the correspondingprivate key. In various embodiments, the CSR is signed using the trustedkey stored in SE 134 during fabrication as mentioned above. Aftersuccessfully validating the CSR at 320, verification system 120 issuesthe corresponding certificate to SE 134 for storage at 322.

Turning now to FIG. 3B, a communication diagram of another enrollmentprocess 300B is depicted. Enrollment process 300B is another embodimentof an enrollment process in which a unique index value is associatedwith the stored identification information 114.

As shown, process 300B begins in a similar manner as process 300A withapplication 242 issuing a request at 302 to read the identificationnumber (or some other portion of information 114 in some embodiments)and application 242 receiving it at 304. At 336, application 242 thenissues, to SEP 210, a request to collect biometric data along with theidentification number. At 338, SEP 210 may instruct biosensor to collectbiometric data, which SEP 210 stores the data with a unique index value.At 340, SEP 210 then provides this unique index value and theidentification number to SE 134. Steps 310-316 may then performed in asimilar manner as discussed above with respect process 300A. Aftergenerating a public-key pair at 316, SE 134 issues, to validation system120, a CSR that, in the illustrated embodiment, includes the uniqueindex value along with the additional information discussed above withrespect process 300A. Upon a successful validation, SE 134 receives acorresponding certificate certifying the public key pair at 344 andincluding the unique index value.

Turning now to FIG. 3C, a communication diagram of an authenticationprocess 350 is depicted. In various embodiments, authentication process350 may be performed when a user of mobile device 130 attempts toauthenticate with a reader 122 in order to prove an identity of theuser.

As shown, authentication process 350 begins at 352 with reader 122issuing a request for identity information 114 to application 242 viaNFC interface 132. At 354, application 242 issues a request to SEP 210to check the identity of the user of mobile device 130. SEP 210 theninstructs biosensor 138 to collect biometric data, which is compared bySEP 210 at 356 against stored biometric data from the previousenrollment process. If a match is detected, SEP 210 provides thecorresponding unique index value to SE 134 at 358. Upon receiving theunique index value, SE 134 verifies that the unique index value matchesthe unique index value associated with the stored identificationinformation 114 at 360 and issues, at 362, the requested information114, which, in the illustrated embodiment, is signed using the privatekey generated during the enrollment process. If, however, the indexvalue does not match the index value associated with the previouslystored information 114, then SE 134 may signal an error and not respondat 360.

Turning now to FIG. 4 , a block diagram of an authentication system 400is depicted. As noted above, in various embodiments, mobile device 130is configured to perform an authentication that includes SE 134confirming whether a holder of an identification document 110 has anattribute satisfying some criterion without providing that attribute.For example, as noted above, a mobile device 130 may be used to confirmthat a user is old enough to purchase a particular product (e.g.,alcohol) without providing the user's date of birth to the merchant. Insome embodiments, device 130 also may provide addition information, butnot all information present on an identification document 110. Forexample, in such an embodiment, device 130 may also provide a photographof the user, but not the user's driver license number. In someembodiments, mobile device 130 may also perform such an authenticationwhen conducting a transaction via an authentication system such assystem 400. In the illustrated embodiment, authentication system 400includes mobile device 130, a merchant system 410, and an authorizationsystem 420. As shown, merchant system 410 may include a reader 412 and abackend 414.

Merchant System 410, in one embodiment, includes one or more computersystems configured to facilitate a financial transaction between a userof mobile device 130 and a merchant. In illustrated embodiment, merchantsystem 410 interacts with mobile device 130 via a reader 412, which mayimplement functionality described above with respect to reader 122.Accordingly, as shown, reader 412 may be configured to issue a request426 for SE 134 to confirm some aspect about information 114 andreceiving a corresponding confirmation 428. In various embodiments,backend 414 of merchant system 410 is a computer system configured toauthorize a transaction and facilitate interfacing with a transactioninstrument provider such as Visa™, American Express™, MasterCard™, etc.Accordingly, in some embodiments, backend 414 may also verify aconfirmation 428 when determining to authorize a transaction. In someembodiments, backend 414 is also configured to perform an enrollmentprocess for merchant system 410 in order to enable merchant system 410to communicate with a mobile device 130.

Authorization system 420, in one embodiment, is a computer system tofacilitate enrolling a merchant system 410. In some embodiments,authorization system 420 may be operated by an authority that issuesidentification document 110 or a trusted third-party that interacts withthe issuing authority. In some embodiments, merchant system 410 maybegin an enrollment by having backend 414 generate a public-key pair andissuing an enrollment request 422 that includes a CSR for the key pair.In some embodiments, enrollment request 422 may also specify whatattribute or attributes that merchant wants SE 134 to confirm. Forexample, in one embodiment, the request 422 may specify that a merchantwants to 1) know whether a user exceeds a particular age threshold(e.g., is over 21 years of age) and 2) be provided with a correspondingphotograph of the user that is present on identification document 110.Authorization system 420 may then validate this request 422, which, insome embodiments, may be performed in a similar manner as discussedabove with respect to request 136. In response to a successfulvalidation the request, in various embodiments, authorization 420 issuesa corresponding digital certificate 424 indicating that merchant system410 is authorized to receive the request information specified in itsenrollment request 422. In some embodiments, upon merchant system 410receiving certificate 424, backend 414 may distribute the certificate toreaders 412 in order to enable them to issue requests 426. In anotherembodiment, rather than providing a merchant system 410 with acertificate, authorization system 420 is configured to make backend 414an intermediate certificate authority, which has the ability to issuecertificates to readers 412 for public key pairs generated by thereaders 412.

When a transaction is conducted after enrollment, a reader 412 isconfigured to issue a request 426 that specifies that certificate 424indicating that a merchant system 410 is authorized to obtain therequested information specified in the certificate 424. In variousembodiments, upon receiving a request 426, SE 134 is configured tovalidate the certificate, which may include issuing a challenge toreader 412 and having backend 414 (or readers 412 in some embodiments)generate a corresponding response. In other embodiments, SE 134 maymerely validate the certificate using the digital signature and publickey specified in the certificate as communication between SE 134 andreader 412 is encrypted in order to prevent a third party from obtainingto certificate 424. After successfully verifying the certificate, SE 134may confirm the identity of the user via biosensor 138 as discussedabove and issue a confirmation 428 providing the requested information114 specified in the certificate 424. Upon receiving this information,in some embodiments, reader 412 may present this information on adisplay to a sells representative operating a reader 412. Reader 412 mayalso present a prompt asking the representative to approve theinformation before enabling backend 414 to communicate with atransaction instrument provider.

Enrollment and authentication processes are described in further detailbelow with respect to FIGS. 5A and 5B.

Turning now to FIG. 5A, a communication diagram of an enrollment process500 is depicted. As noted above, in various embodiments, process 500 maybe performed in order to enable a merchant system to interface withmobile device 130.

As shown, enrollment process 500 begins at 504 with backend 414generating a public key pair to be used in encrypting communicationsbetween mobile devices 130 and reader 122 as well as verifying acorresponding certificate 424. At 504, backend 414 then issues anenrollment request 422 to authorization system 420, where the enrollmentrequest includes a CSR for the generated public-key pair. Afterreceiving the request 422, authorization system 420 validates therequest at 506 and issues a corresponding certificate 424 at 508 uponsuccessful validation.

Turning now to FIG. 5B, a communication diagram of an authenticationprocess 550 is depicted. As noted above, in some embodiments, anauthentication processor 550 may be performed to authenticate someaspect about a person such as during a financial transaction.

As shown, authentication process 550 begins at 552 with reader 412issuing a request 426 for authenticating one or more attributes about auser via an NFC interface to application 242. Upon receiving andvalidating the request, Application 242 issues a request to SEP 210 at554 to ask SEP 210 to check the identity of the user. At 556, SEP 210activates biosensor 138 and receives corresponding biometric data, whichSEP 210 compares against biometric data previously stored in SEP 210during the enrollment of mobile device 130. In response to a successfulmatch, SEP 210 indicates the corresponding unique index value to SE 134at 558. At 560, SE 134 verifies the unique index value against the valuepreviously associated with the identification information 114. Aftersuccessful verification, SE 134 determines what is to be provided to thereader 412 based on the information specified in the receivedcertificate 424 and issues, at 562, the corresponding information, whichmay be signed by the private key established during enrollment of themobile device 130.

Although specific embodiments have been described above, theseembodiments are not intended to limit the scope of the presentdisclosure, even where only a single embodiment is described withrespect to a particular feature. Examples of features provided in thedisclosure are intended to be illustrative rather than restrictiveunless stated otherwise. The above description is intended to cover suchalternatives, modifications, and equivalents as would be apparent to aperson skilled in the art having the benefit of this disclosure.

The scope of the present disclosure includes any feature or combinationof features disclosed herein (either explicitly or implicitly), or anygeneralization thereof, whether or not it mitigates any or all of theproblems addressed herein. Accordingly, new claims may be formulatedduring prosecution of this application (or an application claimingpriority thereto) to any such combination of features. In particular,with reference to the appended claims, features from dependent claimsmay be combined with those of the independent claims and features fromrespective independent claims may be combined in any appropriate mannerand not merely in the specific combinations enumerated in the appendedclaims.

1. A non-transitory computer readable medium having program instructionsstored thereon that are executable by a computer system to performoperations comprising: receiving identification information usable toestablish an identity of a user; storing at least a portion of theidentification information in a secure element of the computer system,wherein the secure element is configured to restrict direct access tothe at least a portion of the identification information by one or moreprocessors of the computer system, and wherein the at least a portion ofthe identification information is associated with an index value that isderived from biometric data collected from the user via a biometricsensor of the computer system; and causing, during an authenticationprocess that involves the identification information, the secure elementto: receive the index value in response to valid biometric data beingcollected from the user via the biometric sensor during theauthentication process; access the at least a portion of theidentification information using the index value; and provide the atleast a portion of the identification information to a requestingcomputer system.
 2. The non-transitory computer readable medium of claim1, wherein the operations further comprise: causing, during theauthentication process, a biometric processor of the computer system to:collect an instance of biometric data from the user via the biometricsensor; compare the collected instance of biometric data to previouslystored biometric data of the user to determine whether the user providedvalid biometric data; and send the index value to the secure element inresponse to a determination that the user provided valid biometric data.3. The non-transitory computer readable medium of claim 1, wherein theoperations further comprise: issuing, to a system that is operated by anauthority that issued an identification document having theidentification information, a request to store the at least a portion ofthe identification information, wherein the storing is performed inresponse to an approval of the request.
 4. The non-transitory computerreadable medium of claim 1, wherein the causing further includescausing, during the authentication process, the secure element to:provide, to the requesting computer system, a digital certificate and adigital signature from the secure element, wherein the digital signatureis generated by the secure element using a private key associated withthe digital certificate, wherein the digital certificate is generated byan issuing authority that issued, to the user, an identificationdocument having the identification information, and wherein the digitalcertificate and the digital signature are usable by the requestingcomputer system to establish the identity of the user.
 5. Thenon-transitory computer readable medium of claim 1, wherein thereceiving includes: reading, via a short-range radio of the computersystem, the identification information from a circuit embedded in anidentification document issued by an authority to the user forestablishing the identity of the user.
 6. The non-transitory computerreadable medium of claim 1, wherein the operations further comprise:storing, in the secure element, a token usable to access another portionof the identification information that includes a photograph of the userstored in an identification document issued to the user by an issuingauthority.
 7. The non-transitory computer readable medium of claim 1,wherein the secure element is configured to: generate a public-key pairusable to establish the identity of the user; issue a certificatesigning request (CSR) for the public-key pair to an issuing authoritythat issued, to the user, an identification document having theidentification information; and receive a certificate for the public-keypair in response to the issuing authority granting the CSR; and provide,to the requesting computer system, a digital signature generated using aprivate key of the public-key pair to establish the identity of theuser.
 8. A computing device, comprising: one or more processors; memoryhaving program instructions stored therein; a biometric sensorconfigured to collect biometric data; and a secure element that includesa processor distinct from the one or more processors and a memorydistinct from the memory having the program instructions, wherein thesecure element is configured to: store at least a portion ofidentification information usable to establish an identity of a user,wherein the at least a portion of identification information is storedin association with an index value derived from biometric data collectedfrom the user via the biometric sensor; restrict direct access to the atleast a portion of identification information by the one or moreprocessors; during an authentication process that involves the at leasta portion of identification information, receive the index value inresponse to the user providing valid biometric data via the biometricsensor; access the at least a portion of identification informationusing the index value; and provide the at least a portion ofidentification information to a requesting computer system.
 9. Thecomputing device of claim 8, wherein the secure element is configuredto: generate a digital signature using a private key that was stored inthe secure element during fabrication of the secure element; send, to anauthorization system, a request for authorization to store, at thesecure element, the at least a portion of identification information,wherein the request identifies an identification number associated withthe identification information and the digital signature; and receive,from the authorization system, a response indicating authorization tostore, at the secure element, the at least a portion of identificationinformation, wherein the response includes a signed version of the atleast a portion of identification information.
 10. The computing deviceof claim 9, wherein the secure element is configured to: obtain theidentification number from a passport having the identification number,wherein the identification number is a passport number.
 11. Thecomputing device of claim 8, wherein the secure element is configuredto: generate a public-key pair that is associated with theidentification information and usable to authenticate the user; issue,to a certificate authority system, a certificate signing request for thepublic-key pair; receive a certificate for the public-key pair inresponse to the certificate authority system granting the certificatesigning request; and sign the at least a portion of the identificationinformation using a private key of the public-key pair prior toproviding the at least a portion of identification information to therequesting computer system.
 12. The computing device of claim 8, whereinthe secure element is configured to: store a token usable to accessanother portion of the identification information, wherein the otherportion includes a photograph of the user.
 13. The computing device ofclaim 8, further comprising: a biometric processor coupled to thebiometric sensor and configured to: collect an instance of biometricdata from the user via the biometric sensor during the authenticationprocess; compare the collected instance of biometric data to previouslystored biometric data of the user to determine whether the user providedvalid biometric data; and send the index value to the secure element inresponse to a determination that the user provided valid biometric data.14. A method, comprising: receiving, by a computer system,identification information usable to establish an identity of a user;storing, by the computer system, at least a portion of theidentification information in a secure element of the computer system,wherein the at least a portion of the identification information isassociated with an index value that is derived from biometric datacollected from the user via a biometric sensor of the computer system;and during an authentication process that involves the identificationinformation, the computer system: collecting an instance of biometricdata from the user via a biometric sensor; obtaining the index value inresponse to valid biometric data being collected from the user via thebiometric sensor; accessing the at least a portion of the identificationinformation using the index value; and providing the at least a portionof the identification information to an external computer system. 15.The method of claim 14, further comprising: providing, by the computersystem and to the external computer system, a digital certificate and adigital signature from the secure element, wherein the digital signatureis generated by the secure element using a private key associated withthe digital certificate, wherein the digital certificate is generated byan issuing authority that issued, to the user, an identificationdocument having the identification information, and wherein the digitalcertificate and the digital signature are usable by the externalcomputer system to establish the identity of the user.
 16. The method ofclaim 14, wherein the storing of the at least a portion of theidentification information is performed in response to receivingauthorization from an authorization system of an issuing authority thatissued, to the user, an identification document having theidentification information.
 17. The method of claim 14, wherein thereceiving includes: reading, by the computer system using a short-rangeradio, the identification information from an identification documentissued to the user by an issuing authority.
 18. The method of claim 14,wherein the at least a portion of the identification informationincludes a photograph of the user that is included in an identificationdocument issued to the user by an issuing authority.
 19. The method ofclaim 14, further comprising: after collecting the instance of biometricdata, the computer system comparing the collected instance of biometricdata to previously stored biometric data of the user; and determining,by the computer system, that the user provided valid biometric inresponse to the collected instance of biometric data matching thepreviously stored biometric data.
 20. The method of claim 14, whereinthe index value corresponds to a particular finger of the user.